Inline Resource
The book has now been published and the content of this chapter has likely changed substanstially.We have a Mystery Guest problem caused by tests that depend on an unseen external resource.
Move the contents of an external resource into the fixture setup logic of the test.
From [RTC]:
To remove the dependency between a test method and some external resource, we incorporate that resource in the test code. This is done by setting up a fixture in the test code that holds the same contents as the resource. This fixture is then used instead of the resource to run the test. A simple example of this refactoring is putting the contents of a file that is used into some string in the test code.
If the contents of the resource are large, chances are high that you are also suffering from Eager Test (see Assertion Roulette on page X). Consider applying an Extract Method[Fowler] refactoring or a Minimize Data (page X) refactoring.
Implementation Notes
The problem with tests that depend on an external resource is that we cannot see the preconditions of the test. The resource may be a file sitting in the file system, the contents of a database or some other thing created outside the test. None of these Prebuilt Fixtures (page X) is visible to the test reader. The solution is to make them visible by inlining the resource into the test. The simplest way to do this is to create the resource from within the test itself. For example, we could build the contents of a text file by writing to the file rather than just referring to a pre-exising file. If we delete the file at the end of the test this also moves us from a Prebuilt Fixture approach to a Persistent Fresh Fixture (see Fresh Fixture on page X) approach. This can have the side effect of making our tests somewhat slower to execute.
A more innovative way to inline the external resource is to replace the actual resource with a Test Stub (page X) initialized within the test. This makes the contents of the resource visible to the test reader. When the system under test (SUT) executes, it uses the Test Stub instead of the real resource.
Another option is to refactor the design of the SUT to improve testabilty. We can apply the Extract Testable Component (page X) refactoring to the part of the SUT that uses the contents of the resource so that it can be tested directly without actually using an external resource. The test passes the contents of the resource to the logic that uses it. We can also test the Humble Object (page X) that reads the resource independently by replacing the extracted component with a Test Stub or Mock Object (page X).
Copyright © 2003-2008 Gerard Meszaros all rights reserved